home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000101_icon-group-sender _Wed Apr 2 09:35:43 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Thu, 3 Apr 1997 06:18:11 MST
  2. Date: Wed, 2 Apr 1997 09:35:43 -0800 (PST)
  3. From: Tom Mitchell <mitch@relay.csd.SGI.COM>
  4. To: Norman Ramsey <nr@cs.virginia.edu>
  5. Cc: tc@charlie.cns.iit.edu, icon-group@cs.arizona.edu
  6. Subject: Re: file locking in unix Icon 
  7. In-Reply-To: <199704011939.OAA19258@archive.cs.Virginia.EDU>
  8. Message-Id: <Pine.SGI.3.94.970402084643.12938F-100000@roll.csd.sgi.com>
  9. Mime-Version: 1.0
  10. Content-Type: TEXT/PLAIN; charset=US-ASCII
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12. Status: RO
  13. Content-Length: 2635
  14.  
  15.  
  16. If you want to go fast and or be reliable there is work to do. 
  17.  
  18. A simple spin loop is brutal on the system.  It is implicit that
  19. another process must run to free the lock.  Thus it is important
  20. to let that other process run.  See the bsd system call nap()  or
  21. sleep(0).  Busy wait loops are evil. 
  22.  
  23. If the system is a true multiprocessing system spin locks might
  24. play as long as the number of possible spinners is equal to or
  25. less than the number of processes AND the time in the lock is
  26. very small compared to the slice time.
  27.  
  28. On a single processor system or an oversubscribed multiprocessing
  29. machine it is also important to ensure fair sharing of the locked
  30. resources.  It is very easy to have one process capture the lock. 
  31. Consider the odds that a given process will time slice out while
  32. holding the lock.  The ratio of locked vs. unlocked time matters
  33. here.  Again see the bsd system call nap() or sleep(0) and
  34. consider "stepping aside"  after the unlock(). 
  35.  
  36. Also if more than one lock or locked file is involved you will
  37. need to eliminate deadlock risks by design.  Check out
  38. "Concurrent Programming... by Gregory Andrews or other operating
  39. system texts like Per Brinch Hanson(sp). 
  40.  
  41. It may be that the best way to get where you need to be is to
  42. look at all the work that needs to be done then hide that in a
  43. small set of modules/functions that you can improve over time. 
  44. Start with something simple and correct then work for speed... 
  45.  
  46. Networking adds more ... 
  47.  
  48.  
  49. On Tue, 1 Apr 1997, Norman Ramsey wrote:
  50. > To: tc@charlie.cns.iit.edu
  51. > Cc: icon-group@cs.arizona.edu
  52. > Subject: Re: file locking in unix Icon 
  53. > 
  54. > Sounds like I'll have to spin:
  55. > 
  56. >   f := &null
  57. >   while /f do f := open("lockfile", "c")
  58. > 
  59. > does this sound right?
  60.  
  61.  
  62. Close but not strong enough of itself without OS support of
  63. exclusive locking of the file by the operating system.  Check out
  64. mail file locking in public packages like pine or elm, also vipw.
  65. Consider a look into perl because there are some perl library
  66. packages that work when the OS does not support strong locking.
  67. i.e. build on a working lock strategy, building from scratch is
  68. hard to get right (but fun). 
  69.  
  70. Know also that NFS does not support locking of files and depends
  71. on an external agent like 'lockd' to do the very hard work and
  72. make it look as if NFS does support locking.  Again watch for
  73. deadlocks. 
  74.  
  75. Spinning forever is a big risk.  Always build in an escape or
  76. some "continue, retry, abort" sequence. 
  77.  
  78.  
  79. > Norman
  80. > 
  81.  
  82. --
  83.   Thomas Mitchell   --  mitch@sgi.com mitch@relay.csd.sgi.com mitch@acm.org
  84.   "Spring has sprung the grass is riz... I wonder where the birdies is."
  85.  
  86.  
  87.